1. Field of the Present Invention
The present invention generally relates to the field of smart cards and more particularly to an improved smart card and method for determining the boundaries of method bodies within converted applet files loaded into a smart card.
2. History of Related Art
Most consumers are familiar with and use credit cards, debit cards, automatic teller machine (ATM) cards, stored value cards, and the like. For many types of transactions, however, the current trend is away from these types of cards and into a class of devices generally referred to as smart cards. A smart card is a plastic, credit-card sized card that includes an electronic device (chip) embedded in the card's bulk plastic. Rather than only employing a magnetic strip to store information, smart cards employ a microprocessor and a memory element embedded within the chip.
Because they have a chip, smart cards can be programmed to operate in a number of varied capacities such as stored value cards, credit cards, debit cards, ATM cards, calling cards, personal identity cards, critical record storage devices, etc. In these varied capacities, a smart card may be designed to use a number of different application programs. Smart cards are compliant with Standard 7816 Parts 1–10 of the International Organization for Standardization (ISO), which are incorporated by reference herein and referred to generally as “ISO 7816.”
Initially, application program development for smart cards was essentially proprietary to the smart card manufacturers or the smart card issuers. Smart card application development has, however, evolved over recent years so that it is no longer proprietary. Through the adoption of open architectures for application development, it is now possible to develop applications that can run on smart cards from different manufacturers, on other devices for the storage of data (i.e., storage devices), or other resource constrained devices that, like smart cards, have small amounts of available memory. Java Card smart card technology is an example of one such open development architecture. It uses the Java™ programming language and employs the Java Card smart card runtime environment (JCRE). The JCRE conforms to ISO 7816 and defines a platform on which applications written in the Java programming language can run on smart cards and other resource-constrained devices. Applications written for the JCRE are referred to as applets and must conform with the Java Card 2.1 Virtual Machine Specification (as revised from time to time) published by Sun Microsystems, Inc., which is incorporated by reference herein and referred to generally as the “JCVM Specification.”
The process of loading an applet onto a smart card for execution requires that the source code of the applet first be converted into a corresponding binary representation of the classes making up the applet. This corresponding binary representation is referred to as a CAP file (converted applet file) and is the file format in which applications are loaded onto smart cards utilizing the JCRE. The CAP file is typically loaded as a block of bytes occupying contiguous space in the non-volatile read/write memory of the smart card by an installer module located on the smart card.
A CAP file consists of a set of components each of which defines differing elements or aspects of the contents of the CAP file. One such component is the Method Component which defines each of the methods (i.e., procedures or routines associated with one or more classes) declared in the package that makes up the CAP file. The following are among the items included in the Method Component: (1) a size item which indicates the number of bytes in the Method Component, (2) a handler count item which indicates the number of exception handler entries in the exception handler array, (3) an exception handlers item which provides relevant information for each exception handler (including a starting offset and a length for indicating the range of bytecodes for which the exception handler is active (i.e., a “catch range”) and further including the starting address of the exception handler), and (4) a methods item which defines each of the variable length methods (i.e., method bodies) declared in the package making up the CAP file with each such method body containing a method header followed by the bytecodes (i.e., instructions) that implement such method body. While each method header contains relevant information defining the requirements for the operand stack, associated parameters being passed to the method body, and local variables for the method body, the method header does not specify the size of the associated method body.
The bytecodes within each method body typically contain operands consisting of various symbolic or unresolved code references which must be resolved prior to execution. The process of resolving these particular operands is generally referred to as linking or resolution and involves looking-up the symbolic reference in a corresponding table present in memory (constant pool) or other storage device or calculating the unresolved relative code reference and replacing the reference with the actual memory address or an internally accessible symbolic reference at which the particular command, function, definition, etc. is stored. The terms “resolve,” “resolution,” “resolving,” and “linking” are used throughout to broadly describe the foregoing process of replacing the unresolved code or symbolic reference within the code or data structure with an internally accessible symbolic reference or actual memory address.
One method utilized by the prior art to implement the resolution process is to access a list of bytecode offsets into each method body, which list designates the applicable bytecodes within each method body requiring resolution (i.e., relocation annotations). This list of bytecode offsets is provided in the form of another component in the CAP file referred to as the Reference Location Component. The Reference Location Component is required by the prior art because the boundaries of each method body (i.e., the beginning and the end of each method body) are not specified in the Method Component. The Reference Location Component is used solely for the resolution process and is not referenced by any other component in a CAP file.
A second method utilized by the prior art to implement the resolution process without accessing the list of relocation annotations contained in the Reference Location Component is to access information contained in another component of the CAP file referred to as the Descriptor Component. The Descriptor Component contains sufficient information to permit parsing and verification of all elements of the CAP file. Consequently, the Descriptor Component contains information on the boundaries of each method body so as to permit parsing and examination of the bytecodes contained within each method body. Because of its lengthy size, however, the Descriptor Component is an optional component of the CAP file, and as such, is not always available.
It would be beneficial to implement an apparatus and method for the efficient linking of CAP files that does not rely upon relocation annotations (such as those provided in the Reference Location Component), but rather which enables the contiguous bytecodes making up the methods item of the Method Component to be examined (and if necessary, their operands resolved) without reliance upon the Descriptor Component.
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description presented herein are not intended to limit the invention to the particular embodiment disclosed. On the contrary, the invention is limited only by the claim language.